The first Web applications were largely server-based with no user interface functionality implemented by client-side scripting. Transitions between user interface states were mainly accomplished with a request and response round-trip over a network between a client device and a server device. A Web browser executing on the client device would send to the server device a Hypertext Transfer Protocol (HTTP) request specifying a Web address (e.g., a URL) that identified the next user interface state (e.g., a new Web page). In response, the server device would send back to the client device a HTTP response including Hypertext Markup Language (HTML) content of the requested user interface state. The Web browser would then update a user interface (e.g., a Web page window) displayed at the client computing device based on the HTML content. Over time, client-side scripting languages, such as ECMAScript®, JavaScript®, ActionScript®, Jscript®, and others, were developed. With these client-side scripting languages, a Web application could be developed that transitioned between user interface states without the request and response round-trip between client and server.
Device Profiles
With the first Web applications, minimizing the number of client-scripting language instructions needed to implement the user interface of a Web application was a relatively simple task because client devices were relatively homogenous. With the emergence of smart phones and tablet computing devices, Web applications are now expected to properly function on heterogeneous client devices with different screen sizes (e.g., 3.5-inch diagonal screen size on some mobile phones vs. 21-inch diagonal screen size on some desktop displays) and different user input mechanisms (e.g., mouse/keyboard input vs. touch screen input). Moreover, proper functioning of a Web application is dependent on user expectations which may vary depending on the characteristics of the device being used. For example, a user may expect one kind of user interface of a Web application on a mobile phone with a touch screen (e.g., large touchable user interface elements, no pop-up windows or overlays, and simple input forms) and another different kind of user interface of the Web application on a desktop or laptop computer with a mouse and keyboard (e.g., clickable user interface elements, pop-up windows or overlays, and more complicated input forms). Consequently, user expectations of Web applications in today's world of heterogeneous personal computing devices often cannot be met with a single user interface design and functionality. Instead, users expect a Web application to present a user interface with functionality appropriate for the device being used.
As more and more Web applications are expected to have different user interfaces and functionality on different types of personal computing devices, a whole new set of challenges face developers of Web applications. A particular set of challenges involves reducing the number of client-side scripting language instructions that need to be authored and maintained to implement the different user interfaces and functionality for the different types of devices.
The software industry, in response, has applied a number of software design strategies to make software development and maintenance tasks easier. Once such strategy is known in the industry as Model-View-Controller (MVC). Under a typical MVC strategy, the software instructions implementing the model, the view, and the controller are developed and maintained separately. Generally, the view implements the look and feel of a user interface. The controller implements user interface event handling and user interface state transitions. And the model implements programmatic interfaces for creating, reading, updating, and deleting underlying user data. A theoretical benefit of the MVC strategy is that the implementation of one of the model, view, or controller can be changed without requiring changes to the other two. For example, the look and feel of the user interface can be changed without having to change how user interface events are handled or how the underlying user data is modeled.
However, the typical MVC strategy does not fully solve the problem of reducing the number of software instructions needed to implement a Web application that is to provide different user interfaces and functionality on different types of computing devices. The typical MVC strategy would require the development of a separate Web application for each different type of computing device. The separate Web applications would have different views and possibly different controllers and models for the different types of computing devices. Unfortunately, many software instructions may be duplicated between the separate Web applications. This is undesirable from a software development and maintenance standpoint because it creates more work for the developer and increases the probability of introducing defects (i.e., “software bugs”). For these reasons, the typical MVC strategy does not provide adequate reduction in the number of software instructions.
A development solution is required that allows Web application developers to more easily develop a Web application that provides different user interfaces and associated functionality on different types of computing devices. The solution should not only address the problem of multiple Web applications for the different types of computing devices, but should also provide a solution to the more general problem of reducing the number of software instructions needed to implement a Web application that is to provide different user interfaces and functionality on different types of computing devices.
Deep Linking and Browser History Support
In the case of the first Web applications, a user could navigate directly to a user interface state of a Web application by entering the Web address (e.g., a URL) in the address bar of the Web browser. For example, the initial user interface state of a Web application may correspond to the home page of a shopping Web site. A second user interface state may correspond to a Web page listing products available for purchase hyperlinked from the home page. With the first Web applications, a user could directly navigate to the product listing Web page as if the user had navigated to it from the home page simply by entering the Web address of the product listing Web page in the address bar of the user's Web browser. The user interface states of the first Web applications could also be bookmarked using the Web browser's bookmarking feature.
This type of Web address that links directly to a user interface state is referred to in the industry as a “deep link”. The act of providing a deep link to a Web browser to navigate directly to a user interface state bypassing any initial and intermediary user interface states of a Web application is referred to in the industry as “deep linking”. Deep linking has at least two benefits to users. First, a deep link can be recorded (e.g., in the form of a bookmark) allowing a user to return to a specific user interface state of a Web application without having to navigate from an initial user interface state to the specific user interface state. Further, a deep link can be shared among users (e.g., in an e-mail message) allowing recipients of the deep link to directly navigate to a specific user interface state without having to understand how to navigate from an initial user interface state to the specific user interface state.
Further, deep linking is related to the browsing history functionality of Web browsers. Generally, a user interface state for which there is a corresponding deep link can be recorded by a Web browser in a browsing history. Consequently, a user can navigate directly to a previously visited user interface state that is recorded as a deep link in the browsing history. For example, the user may invoke the Web browser's back button to return to the previously visited web page.
Today, many Web applications developed using a client-side scripting language such as JavaScript®, ActionScript®, and Jscript® can be used to present user interface states for which there are no corresponding deep links. Consequently, a user cannot navigate directly to these user interface states by entering a Web address in the address bar of a Web browser or otherwise providing a Web address to the Web browser (e.g., by invoking bookmark or invoking the web browser's back button). Instead, the user is required to navigate directly to an initial user interface state (e.g., a home page) and then navigate state by state (e.g., by clicking on hyperlinks or interacting with user interface elements) from the initial user interface state to the target user interface state. This is cumbersome for the user and decreases the overall usability of the Web application. Further, the target user interface state cannot be shared with other users in the form of a deep link.
A deep linking solution is required that allows Web application developers to more easily develop a Web application that presents user interface states using a client-side scripting language to which a user can directly navigate using deep links. The present invention provides a solution for this and other needs.